Systems and methods for determining a topology of an ethernet ring in a building management system

ABSTRACT

A system and method of determining a topology of devices in an Ethernet network of a building management system (BMS). The method includes discovering a number and identification of devices within the Ethernet ring. The method further includes, for each device discovered in the Ethernet ring, disabling an Ethernet port of one of the device in the Ethernet ring; broadcasting a ring port request onto the Ethernet ring; receiving a ring port response from each of the devices having received the ring port request; and incrementing a count associated with each device based on receiving a ring port response from the device. The method then repeats the above steps until each device in the Ethernet ring has had an Ethernet port disabled. The method further includes determining the topology of the devices in the Ethernet ring by ordering the devices in the Ethernet ring based on the value of the count associated with each device.

BACKGROUND

The present disclosure relates generally to building management systems.The present disclosure relates more particularly to systems and methodsfor identifying faults in a building management system Ethernet ringnetwork, such as device faults, cabling faults, and/or cabling errors.

A building management system (BMS) is, in general, a system of devicesconfigured to control, monitor, and manage equipment in or around abuilding or building area. A BMS can include a heating, ventilation, andair conditioning (HVAC) system, a security system, a lighting system, afire alerting system, another system that is capable of managingbuilding functions or devices, or any combination thereof. BMS devicesmay be installed in any environment (e.g., an indoor area or an outdoorarea) and the environment may include any number of buildings, spaces,zones, rooms, or areas. A BMS may include a variety of devices (e.g.,HVAC devices, controllers, chillers, fans, sensors, etc.) configured tofacilitate monitoring and controlling the building space. Throughoutthis disclosure, such devices are referred to as BMS devices or buildingequipment.

In some BMS systems, at least some of the devices are connected in anetwork and particularly, in an Ethernet network. In many system, theEthernet network may be configured in a ring topology such as a ringusing a Media Redundancy Protocol (MRP) ring protocol. MRP rings canprovide for single fault tolerances such that connectivity within thering can be broken (e.g. a device fails or goes offline, or an Ethernetcable between devices is cut or disconnected) without impacting thenetwork connectivity of the (other) devices in the ring.

While MRP rings provide a robust ring topology for a network there iscurrently no mechanism to accurately determine the order of the devicesin the ring or how the devices are connected to each other (e.g. whichswitch port on a device is connected to a specific neighboring device).This data could be useful to verify that the devices in the MRP ring areconnected correctly as per the system design. Further, device order andconnection data can be useful in troubleshooting an MRP ring when errorsor faults occur. Thus, it would be advantageous to have systems andmethods that could automatically determine an order and connectionscheme of devices connected in an MRP or other Ethernet ring topology.

SUMMARY

One implementation of the present disclosure is a method for determininga topology of devices in an Ethernet ring. The method includesbroadcasting a device discovery command from a ring topology generatorto the devices in the Ethernet ring; and receiving device discoveryinformation from one or more of the devices in the Ethernet ring at thering topology generator. The method also includes querying a ringsupervisor to confirm that the Ethernet ring is closed and to determinewhich Ethernet port of the ring supervisor is connected to Ethernet ringas the forwarding port. Additionally, the ring topology generatorconfigured to, for each discovered device in the Ethernet ring: (i)disabling an Ethernet port of one of the devices in the Ethernet ring;(ii) verifying the Ethernet ring is open; (iii) broadcasting a ring portrequest onto the Ethernet ring from the ring supervisor; (iv) receivinga ring port response from each of the devices having received the ringport request; (v) incrementing a count associated with each device basedon receiving a ring port response from the device; (vi) re-enabling theEthernet port of the one of the devices in the Ethernet ring; and (vii)repeating steps (i) through (vi) until each device in the Ethernet ringhas had an Ethernet port disabled. The method further includesdetermining the topology of the devices of the Ethernet ring by orderingthe devices in the Ethernet ring based on the value of the countassociated with each device. The device having the highest count valuebeing closest to the forwarding port of the ring supervisor and thedevice having the lowest count value being furthest from the forwardingport of the ring supervisor.

A further implementation of the present disclosure is a system fordetermining a topology of an Ethernet ring. The system includes a numberof Ethernet devices configured in an Ethernet ring. The system furtherincludes a ring supervisor. The ring supervisor is integral to theEthernet ring and configured to manage data flow within the Ethernetring. The system further includes a ring topology generator configuredto broadcast a device discovery command from a ring topology generatorto the devices in the Ethernet ring. The ring topology generator isfurther configured to receive device discovery information from one ormore of the plurality of devices in the Ethernet ring, the receiveddevice discovery information indicating a discovered device. The ringtopology generator further configured to instruct the ring supervisoryto initialize one Ethernet port connected to the ring as the forwardingport, and disable the other port connected to the Ethernet ring. Thering topology generator further configured to execute the followinginstructions for each of the discovered devices: (i) disable an Ethernetport of one of the devices in the Ethernet ring; (ii) verify theEthernet ring is open; (iii) broadcast a ring port request onto theEthernet ring from the forwarding port of the ring supervisor; (iv)receive a ring port response from each of the devices having receivedthe ring port request; (v) increment a count associated with each devicebased on receiving a ring port response from the device; (vi) re-enablethe Ethernet port of the one of the devices in the Ethernet ring; and(vii) repeat steps (i) through (vi) until each device in the Ethernetring has had an Ethernet port disabled. The ring topology generatorfurther configured to determine the topology of the devices of theEthernet ring by ordering the devices in the Ethernet ring based on thevalue of the count associated with each devices. The device having thehighest count value being closest to the forwarding port of the ringsupervisor and the device having the lowest count value being furthestfrom the forwarding port of the ring supervisor.

A further implementation of the present disclosure is a method ofdetermining a topology of devices in an Ethernet ring. The methodincludes discovering a number and identification of devices within anEthernet ring. The method further includes, for each devices discoveredin the Ethernet ring: (i) disabling an Ethernet port of one of thedevices in the Ethernet ring; (ii) verifying the Ethernet ring is open;(iii) broadcasting a ring port request onto the Ethernet ring from theforwarding port of the ring supervisor; (iv) receiving a ring portresponse from each of the devices having received the ring port request;(v) incrementing a count associated with each device based on receivinga ring port response from the device; (vi) re-enabling the Ethernet portof the one of the devices in the Ethernet ring; and (vii) repeatingsteps (i) through (vi) until each device in the Ethernet ring has had anEthernet port disabled. The method further includes determining thetopology of the devices of the Ethernet ring by ordering the devices inthe Ethernet ring based on the value of the count associated with eachdevices. The device having the highest count value being closest to theforwarding port of the ring supervisor and the device having the lowestcount value being furthest from the forwarding port of the ringsupervisor.

Those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the devices and/orprocesses described herein, as defined solely by the claims, will becomeapparent in the detailed description set forth herein and taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a building equipped with a building managementsystem (BMS) and a HVAC system, according to some embodiments.

FIG. 2 is a schematic of a waterside system which can be used as part ofthe HVAC system of FIG. 1, according to some embodiments.

FIG. 3 is a block diagram illustrating an airside system which can beused as part of the HVAC system of FIG. 1, according to someembodiments.

FIG. 4 is a block diagram illustrating a BMS which can be used in thebuilding of FIG. 1, according to some embodiments.

FIG. 5 is a block diagram illustrating a network connected to aplurality of devices, according to some embodiments.

FIG. 6 is a data flow chart illustrating a process for discoveringdevices in an Ethernet ring, according to some embodiments.

FIG. 7 is a data flow chart illustrating an Ethernet port orientationprocess, according to some embodiments.

FIG. 8 is a data flow chart illustrating a diagnostic flow to establishthat the Ethernet network of FIG. 5 is in a closed status, according tosome embodiments.

FIG. 9 is a flow diagram illustrating a process for determining atopology of an Ethernet ring, according to some embodiments.

DETAILED DESCRIPTION

Building Management System and HVAC System

Referring now to FIGS. 1-4, an exemplary building management system(BMS) and a heating, ventilation, and air conditioning (HVAC) system inwhich the systems and methods of the present disclosure can beimplemented are shown, according to an exemplary embodiment. Referringparticularly to FIG. 1, a perspective view of a building 10 is shown.Building 10 is served by a BMS. A BMS is, in general, a system ofdevices configured to control, monitor, and manage equipment in oraround a building or building area. A BMS can include, for example, aHVAC system, a security system, a lighting system, a fire alertingsystem, any other system that is capable of managing building functionsor devices, or any combination thereof.

The BMS that serves building 10 includes an HVAC system 100. HVAC system100 can include a plurality of HVAC devices (e.g., heaters, chillers,air handling units, pumps, fans, thermal energy storage, etc.)configured to provide heating, cooling, ventilation, or other servicesfor building 10. For example, HVAC system 100 is shown to include awaterside system 120 and an airside system 130. Waterside system 120 canprovide a heated or chilled fluid to an air handling unit of airsidesystem 130. Airside system 130 can use the heated or chilled fluid toheat or cool an airflow provided to building 10. An exemplary watersidesystem and airside system which can be used in HVAC system 100 aredescribed in greater detail with reference to FIGS. 2-3.

HVAC system 100 is shown to include a chiller 102, a boiler 104, and arooftop air handling unit (AHU) 106. Waterside system 120 can use boiler104 and chiller 102 to heat or cool a working fluid (e.g., water,glycol, etc.) and can circulate the working fluid to AHU 106. In variousembodiments, the HVAC devices of waterside system 120 can be located inor around building 10 (as shown in FIG. 1) or at an offsite locationsuch as a central plant (e.g., a chiller plant, a steam plant, a heatplant, etc.). The working fluid can be heated in boiler 104 or cooled inchiller 102, depending on whether heating or cooling is required inbuilding 10. Boiler 104 can add heat to the circulated fluid, forexample, by burning a combustible material (e.g., natural gas) or usingan electric heating element. Chiller 102 can place the circulated fluidin a heat exchange relationship with another fluid (e.g., a refrigerant)in a heat exchanger (e.g., an evaporator) to absorb heat from thecirculated fluid. The working fluid from chiller 102 and/or boiler 104can be transported to AHU 106 via piping 108.

AHU 106 can place the working fluid in a heat exchange relationship withan airflow passing through AHU 106 (e.g., via one or more stages ofcooling coils and/or heating coils). The airflow can be, for example,outside air, return air from within building 10, or a combination ofboth. AHU 106 can transfer heat between the airflow and the workingfluid to provide heating or cooling for the airflow. For example, AHU106 can include one or more fans or blowers configured to pass theairflow over or through a heat exchanger containing the working fluid.The working fluid can then return to chiller 102 or boiler 104 viapiping 110.

Airside system 130 can deliver the airflow supplied by AHU 106 (i.e.,the supply airflow) to building 10 via air supply ducts 112 and canprovide return air from building 10 to AHU 106 via air return ducts 114.In some embodiments, airside system 130 includes multiple variable airvolume (VAV) units 116. For example, airside system 130 is shown toinclude a separate VAV unit 116 on each floor or zone of building 10.VAV units 116 can include dampers or other flow control elements thatcan be operated to control an amount of the supply airflow provided toindividual zones of building 10. In other embodiments, airside system130 delivers the supply airflow into one or more zones of building 10(e.g., via supply ducts 112) without using intermediate VAV units 116 orother flow control elements. AHU 106 can include various sensors (e.g.,temperature sensors, pressure sensors, etc.) configured to measureattributes of the supply airflow. AHU 106 can receive input from sensorslocated within AHU 106 and/or within the building zone and can adjustthe flow rate, temperature, or other attributes of the supply airflowthrough AHU 106 to achieve set-point conditions for the building zone.

Referring now to FIG. 2, a block diagram of a waterside system 200 isshown, according to an exemplary embodiment. In various embodiments,waterside system 200 can supplement or replace waterside system 120 inHVAC system 100 or can be implemented separate from HVAC system 100.When implemented in HVAC system 100, waterside system 200 can include asubset of the HVAC devices in HVAC system 100 (e.g., boiler 104, chiller102, pumps, valves, etc.) and can operate to supply a heated or chilledfluid to AHU 106. The HVAC devices of waterside system 200 can belocated within building 10 (e.g., as components of waterside system 120)or at an offsite location such as a central plant.

In FIG. 2, waterside system 200 is shown as a central plant having aplurality of subplants 202-212. Subplants 202-212 are shown to include aheater subplant 202, a heat recovery chiller subplant 204, a chillersubplant 206, a cooling tower subplant 208, a hot thermal energy storage(TES) subplant 210, and a cold thermal energy storage (TES) subplant212. Subplants 202-212 consume resources (e.g., water, natural gas,electricity, etc.) from utilities to serve the thermal energy loads(e.g., hot water, cold water, heating, cooling, etc.) of a building orcampus. For example, heater subplant 202 can be configured to heat waterin a hot water loop 214 that circulates the hot water between heatersubplant 202 and building 10. Chiller subplant 206 can be configured tochill water in a cold water loop 216 that circulates the cold waterbetween chiller subplant 206 and the building 10. Heat recovery chillersubplant 204 can be configured to transfer heat from cold water loop 216to hot water loop 214 to provide additional heating for the hot waterand additional cooling for the cold water. Condenser water loop 218 canabsorb heat from the cold water in chiller subplant 206 and reject theabsorbed heat in cooling tower subplant 208 or transfer the absorbedheat to hot water loop 214. Hot TES subplant 210 and cold TES subplant212 can store hot and cold thermal energy, respectively, for subsequentuse.

Hot water loop 214 and cold water loop 216 can deliver the heated and/orchilled water to air handlers located on the rooftop of building 10(e.g., AHU 106) or to individual floors or zones of building 10 (e.g.,VAV units 116). The air handlers push air past heat exchangers (e.g.,heating coils or cooling coils) through which the water flows to provideheating or cooling for the air. The heated or cooled air can bedelivered to individual zones of building 10 to serve the thermal energyloads of building 10. The water then returns to subplants 202-212 toreceive further heating or cooling.

Although subplants 202-212 are shown and described as heating andcooling water for circulation to a building, it is understood that anyother type of working fluid (e.g., glycol, CO2, etc.) can be used inplace of or in addition to water to serve the thermal energy loads. Inother embodiments, subplants 202-212 can provide heating and/or coolingdirectly to the building or campus without requiring an intermediateheat transfer fluid. These and other variations to waterside system 200are within the teachings of the present invention.

Each of subplants 202-212 can include a variety of equipment configuredto facilitate the functions of the subplant. For example, heatersubplant 202 is shown to include a plurality of heating elements 220(e.g., boilers, electric heaters, etc.) configured to add heat to thehot water in hot water loop 214. Heater subplant 202 is also shown toinclude several pumps 222 and 224 configured to circulate the hot waterin hot water loop 214 and to control the flow rate of the hot waterthrough individual heating elements 220. Chiller subplant 206 is shownto include a plurality of chillers 232 configured to remove heat fromthe cold water in cold water loop 216. Chiller subplant 206 is alsoshown to include several pumps 234 and 236 configured to circulate thecold water in cold water loop 216 and to control the flow rate of thecold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality ofheat recovery heat exchangers 226 (e.g., refrigeration circuits)configured to transfer heat from cold water loop 216 to hot water loop214. Heat recovery chiller subplant 204 is also shown to include severalpumps 228 and 230 configured to circulate the hot water and/or coldwater through heat recovery heat exchangers 226 and to control the flowrate of the water through individual heat recovery heat exchangers 226.Cooling tower subplant 208 is shown to include a plurality of coolingtowers 238 configured to remove heat from the condenser water incondenser water loop 218. Cooling tower subplant 208 is also shown toinclude several pumps 240 configured to circulate the condenser water incondenser water loop 218 and to control the flow rate of the condenserwater through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configuredto store the hot water for later use. Hot TES subplant 210 can alsoinclude one or more pumps or valves configured to control the flow rateof the hot water into or out of hot TES tank 242. Cold TES subplant 212is shown to include cold TES tanks 244 configured to store the coldwater for later use. Cold TES subplant 212 can also include one or morepumps or valves configured to control the flow rate of the cold waterinto or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in waterside system 200(e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines inwaterside system 200 include an isolation valve associated therewith.Isolation valves can be integrated with the pumps or positioned upstreamor downstream of the pumps to control the fluid flows in watersidesystem 200. In various embodiments, waterside system 200 can includemore, fewer, or different types of devices and/or subplants based on theparticular configuration of waterside system 200 and the types of loadsserved by waterside system 200.

Referring now to FIG. 3, a block diagram of an airside system 300 isshown, according to an exemplary embodiment. In various embodiments,airside system 300 can supplement or replace airside system 130 in HVACsystem 100 or can be implemented separate from HVAC system 100. Whenimplemented in HVAC system 100, airside system 300 can include a subsetof the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116,ducts 112-114, fans, dampers, etc.) and can be located in or aroundbuilding 10. Airside system 300 can operate to heat or cool an airflowprovided to building 10 using a heated or chilled fluid provided bywaterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type airhandling unit (AHU) 302. Economizer-type AHUs vary the amount of outsideair and return air used by the air handling unit for heating or cooling.For example, AHU 302 can receive return air 304 from building zone 306via return air duct 308 and can deliver supply air 310 to building zone306 via supply air duct 312. In some embodiments, AHU 302 is a rooftopunit located on the roof of building 10 (e.g., AHU 106 as shown inFIG. 1) or otherwise positioned to receive return air 304 and outsideair 314. AHU 302 can be configured to operate an exhaust air damper 316,mixing damper 318, and outside air damper 320 to control an amount ofoutside air 314 and return air 304 that combine to form supply air 310.Any return air 304 that does not pass through mixing damper 318 can beexhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 can be operated by an actuator. For example,exhaust air damper 316 can be operated by actuator 324, mixing damper318 can be operated by actuator 326, and outside air damper 320 can beoperated by actuator 328. Actuators 324-328 can communicate with an AHUcontroller 330 via a communications link 332. Actuators 324-328 canreceive control signals from AHU controller 330 and can provide feedbacksignals to AHU controller 330. Feedback signals can include, forexample, an indication of a current actuator or damper position, anamount of torque or force exerted by the actuator, diagnosticinformation (e.g., results of diagnostic tests performed by actuators324-328), status information, commissioning information, configurationsettings, calibration data, and/or other types of information or datathat can be collected, stored, or used by actuators 324-328. AHUcontroller 330 can be an economizer controller configured to use one ormore control algorithms (e.g., state-based algorithms, extremum seekingcontrol (ESC) algorithms, proportional-integral (PI) control algorithms,proportional-integral-derivative (PID) control algorithms, modelpredictive control (MPC) algorithms, feedback control algorithms, etc.)to control actuators 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil334, a heating coil 336, and a fan 338 positioned within supply air duct312. Fan 338 can be configured to force supply air 310 through coolingcoil 334 and/or heating coil 336 and provide supply air 310 to buildingzone 306. AHU controller 330 can communicate with fan 338 viacommunications link 340 to control a flow rate of supply air 310. Insome embodiments, AHU controller 330 controls an amount of heating orcooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 can receive a chilled fluid from waterside system 200(e.g., from cold water loop 216) via piping 342 and can return thechilled fluid to waterside system 200 via piping 344. Valve 346 can bepositioned along piping 342 or piping 344 to control a flow rate of thechilled fluid through cooling coil 334. In some embodiments, coolingcoil 334 includes multiple stages of cooling coils that can beindependently activated and deactivated (e.g., by AHU controller 330, byBMS controller 366, etc.) to modulate an amount of cooling applied tosupply air 310.

Heating coil 336 can receive a heated fluid from waterside system 200(e.g., from hot water loop 214) via piping 348 and can return the heatedfluid to waterside system 200 via piping 350. Valve 352 can bepositioned along piping 348 or piping 350 to control a flow rate of theheated fluid through heating coil 336. In some embodiments, heating coil336 includes multiple stages of heating coils that can be independentlyactivated and deactivated (e.g., by AHU controller 330, by BMScontroller 366, etc.) to modulate an amount of heating applied to supplyair 310.

Each of valves 346 and 352 can be controlled by an actuator. Forexample, valve 346 can be controlled by actuator 354 and valve 352 canbe controlled by actuator 356. Actuators 354-356 can communicate withAHU controller 330 via communications links 358-360. Actuators 354-356can receive control signals from AHU controller 330 and can providefeedback signals to controller 330. In some embodiments, AHU controller330 receives a measurement of the supply air temperature from atemperature sensor 362 positioned in supply air duct 312 (e.g.,downstream of cooling coil 334 and/or heating coil 336). AHU controller330 can also receive a measurement of the temperature of building zone306 from a temperature sensor 364 located in building zone 306.

In some embodiments, AHU controller 330 operates valves 346 and 352 viaactuators 354-356 to modulate an amount of heating or cooling providedto supply air 310 (e.g., to achieve a set-point temperature for supplyair 310 or to maintain the temperature of supply air 310 within aset-point temperature range). The positions of valves 346 and 352 affectthe amount of heating or cooling provided to supply air 310 by coolingcoil 334 or heating coil 336 and may correlate with the amount of energyconsumed to achieve a desired supply air temperature. AHU controller 330can control the temperature of supply air 310 and/or building zone 306by activating or deactivating coils 334-336, adjusting a speed of fan338, or a combination thereof.

Still referring to FIG. 3, airside system 300 is shown to include abuilding management system (BMS) controller 366 and a client device 368.BMS controller 366 can include one or more computer systems (e.g.,servers, supervisory controllers, subsystem controllers, etc.) thatserve as system level controllers, application or data servers, headnodes, or master controllers for airside system 300, waterside system200, HVAC system 100, and/or other controllable systems that servebuilding 10. BMS controller 366 can communicate with multiple downstreambuilding systems or subsystems (e.g., HVAC system 100, a securitysystem, a lighting system, waterside system 200, etc.) via acommunications link 370 according to like or disparate protocols (e.g.,LON, BACnet, etc.). In various embodiments, AHU controller 330 and BMScontroller 366 can be separate (as shown in FIG. 3) or integrated. In anintegrated implementation, AHU controller 330 can be a software moduleconfigured for execution by a processor of BMS controller 366.

In some embodiments, AHU controller 330 receives information from BMScontroller 366 (e.g., commands, setpoints, operating boundaries, etc.)and provides information to BMS controller 366 (e.g., temperaturemeasurements, valve or actuator positions, operating statuses,diagnostics, etc.). For example, AHU controller 330 can provide BMScontroller 366 with temperature measurements from temperature sensors362-364, equipment on/off states, equipment operating capacities, and/orany other information that can be used by BMS controller 366 to monitoror control a variable state or condition within building zone 306.

Client device 368 can include one or more human-machine interfaces orclient interfaces (e.g., graphical user interfaces, reportinginterfaces, text-based computer interfaces, client-facing web services,web servers that provide pages to web clients, etc.) for controlling,viewing, or otherwise interacting with HVAC system 100, its subsystems,and/or devices. Client device 368 can be a computer workstation, aclient terminal, a remote or local interface, or any other type of userinterface device. Client device 368 can be a stationary terminal or amobile device. For example, client device 368 can be a desktop computer,a computer server with a user interface, a laptop computer, a tablet, asmartphone, a PDA, or any other type of mobile or non-mobile device.Client device 368 can communicate with BMS controller 366 and/or AHUcontroller 330 via communications link 372.

Referring now to FIG. 4, a block diagram of a building management system(BMS) 400 is shown, according to an exemplary embodiment. BMS 400 can beimplemented in building 10 to automatically monitor and control variousbuilding functions. BMS 400 is shown to include BMS controller 366 and aplurality of building subsystems 428. Building subsystems 428 are shownto include a building electrical subsystem 434, an informationcommunication technology (ICT) subsystem 436, a security subsystem 438,a HVAC subsystem 440, a lighting subsystem 442, a lift/escalatorssubsystem 432, and a fire safety subsystem 430. In various embodiments,building subsystems 428 can include fewer, additional, or alternativesubsystems. For example, building subsystems 428 can also oralternatively include a refrigeration subsystem, an advertising orsignage subsystem, a cooking subsystem, a vending subsystem, a printeror copy service subsystem, or any other type of building subsystem thatuses controllable equipment and/or sensors to monitor or controlbuilding 10. In some embodiments, building subsystems 428 includewaterside system 200 and/or airside system 300, as described withreference to FIGS. 2-3.

Each of building subsystems 428 can include any number of devices,controllers, and connections for completing its individual functions andcontrol activities. HVAC subsystem 440 can include many of the samecomponents as HVAC system 100, as described with reference to FIGS. 1-3.For example, HVAC subsystem 440 can include a chiller, a boiler, anynumber of air handling units, economizers, field controllers,supervisory controllers, actuators, temperature sensors, and otherdevices for controlling the temperature, humidity, airflow, or othervariable conditions within building 10. Lighting subsystem 442 caninclude any number of light fixtures, ballasts, lighting sensors,dimmers, or other devices configured to controllably adjust the amountof light provided to a building space. Security subsystem 438 caninclude occupancy sensors, video surveillance cameras, digital videorecorders, video processing servers, intrusion detection devices, accesscontrol devices (e.g., card access, etc.) and servers, or othersecurity-related devices.

Still referring to FIG. 4, BMS controller 366 is shown to include acommunications interface 407 and a BMS interface 409. Interface 407 canfacilitate communications between BMS controller 366 and externalapplications (e.g., monitoring and reporting applications 422,enterprise control applications 426, remote systems and applications444, applications residing on client devices 448, etc.) for allowinguser control, monitoring, and adjustment to BMS controller 366 and/orsubsystems 428. Interface 407 can also facilitate communications betweenBMS controller 366 and client devices 448. BMS interface 409 canfacilitate communications between BMS controller 366 and buildingsubsystems 428 (e.g., HVAC, lighting security, lifts, powerdistribution, business, etc.).

Interfaces 407, 409 can be or include wired or wireless communicationsinterfaces (e.g., jacks, antennas, transmitters, receivers,transceivers, wire terminals, etc.) for conducting data communicationswith building subsystems 428 or other external systems or devices. Invarious embodiments, communications via interfaces 407, 409 can bedirect (e.g., locally wired or wireless communications) or via acommunications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.). For example, interfaces 407, 409 can include an Ethernetcard and port for sending and receiving data via an Ethernet-basedcommunications link or network. In another example, the interfaces 407,409 can include a Wi-Fi transceiver for communicating via a wirelesscommunications network. In another example, one or more of interfaces407, 409 can include cellular or mobile phone communicationstransceivers. In one embodiment, communications interface 407 is a powerline communications interface and BMS interface 409 is an Ethernetinterface. In other embodiments, communications interface 407 and BMSinterface 409 are Ethernet interfaces or are the same Ethernetinterface.

Still referring to FIG. 4, BMS controller 366 is shown to include aprocessing circuit 404 including a processor 406 and memory 408.Processing circuit 404 can be communicably connected to BMS interface409 and/or communications interface 407 such that processing circuit 404and the various components thereof can send and receive data viainterfaces 407, 409. Processor 406 can be implemented as a generalpurpose processor, an application specific integrated circuit (ASIC),one or more field programmable gate arrays (FPGAs), a group ofprocessing components, or other suitable electronic processingcomponents.

Memory 408 (e.g., memory, memory unit, storage device, etc.) can includeone or more devices (e.g., RAM, ROM, Flash memory, hard disk storage,etc.) for storing data and/or computer code for completing orfacilitating the various processes, layers and modules described in thepresent application. Memory 408 can be or include volatile memory ornon-volatile memory. Memory 408 can include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present application. According to anexemplary embodiment, memory 408 is communicably connected to processor406 via processing circuit 404 and includes computer code for executing(e.g., by processing circuit 404 and/or processor 406) one or moreprocesses described herein.

In some embodiments, BMS controller 366 is implemented within a singlecomputer (e.g., one server, one housing, etc.). In various otherembodiments BMS controller 366 can be distributed across multipleservers or computers (e.g., that can exist in distributed locations).Further, while FIG. 4 shows applications 422 and 426 as existing outsideof BMS controller 366, in some embodiments, applications 422 and 426 canbe hosted within BMS controller 366 (e.g., within memory 408).

Still referring to FIG. 4, memory 408 is shown to include an enterpriseintegration layer 410, an automated measurement and validation (AM&V)layer 412, a demand response (DR) layer 414, a fault detection anddiagnostics (FDD) layer 416, an integrated control layer 418, and abuilding subsystem integration later 420. Layers 410-420 can beconfigured to receive inputs from building subsystems 428 and other datasources, determine optimal control actions for building subsystems 428based on the inputs, generate control signals based on the optimalcontrol actions, and provide the generated control signals to buildingsubsystems 428. The following paragraphs describe some of the generalfunctions performed by each of layers 410-420 in BMS 400.

Enterprise integration layer 410 can be configured to serve clients orlocal applications with information and services to support a variety ofenterprise-level applications. For example, enterprise controlapplications 426 can be configured to provide subsystem-spanning controlto a graphical user interface (GUI) or to any number of enterprise-levelbusiness applications (e.g., accounting systems, user identificationsystems, etc.). Enterprise control applications 426 can also oralternatively be configured to provide configuration GUIs forconfiguring BMS controller 366. In yet other embodiments, enterprisecontrol applications 426 can work with layers 410-420 to optimizebuilding performance (e.g., efficiency, energy use, comfort, or safety)based on inputs received at interface 407 and/or BMS interface 409.

Building subsystem integration layer 420 can be configured to managecommunications between BMS controller 366 and building subsystems 428.For example, building subsystem integration layer 420 can receive sensordata and input signals from building subsystems 428 and provide outputdata and control signals to building subsystems 428. Building subsystemintegration layer 420 can also be configured to manage communicationsbetween building subsystems 428. Building subsystem integration layer420 translate communications (e.g., sensor data, input signals, outputsignals, etc.) across a plurality of multi-vendor/multi-protocolsystems.

Demand response layer 414 can be configured to optimize resource usage(e.g., electricity use, natural gas use, water use, etc.) and/or themonetary cost of such resource usage in response to satisfy the demandof building 10. The optimization can be based on time-of-use prices,curtailment signals, energy availability, or other data received fromutility providers, distributed energy generation systems 424, fromenergy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or fromother sources. Demand response layer 414 can receive inputs from otherlayers of BMS controller 366 (e.g., building subsystem integration layer420, integrated control layer 418, etc.). The inputs received from otherlayers can include environmental or sensor inputs such as temperature,carbon dioxide levels, relative humidity levels, air quality sensoroutputs, occupancy sensor outputs, room schedules, and the like. Theinputs can also include inputs such as electrical use (e.g., expressedin kWh), thermal load measurements, pricing information, projectedpricing, smoothed pricing, curtailment signals from utilities, and thelike.

According to an exemplary embodiment, demand response layer 414 includescontrol logic for responding to the data and signals it receives. Theseresponses can include communicating with the control algorithms inintegrated control layer 418, changing control strategies, changingsetpoints, or activating/deactivating building equipment or subsystemsin a controlled manner. Demand response layer 414 can also includecontrol logic configured to determine when to utilize stored energy. Forexample, demand response layer 414 can determine to begin using energyfrom energy storage 427 just prior to the beginning of a peak use hour.

In some embodiments, demand response layer 414 includes a control moduleconfigured to actively initiate control actions (e.g., automaticallychanging setpoints) which minimize energy costs based on one or moreinputs representative of or based on demand (e.g., price, a curtailmentsignal, a demand level, etc.). In some embodiments, demand responselayer 414 uses equipment models to determine an optimal set of controlactions. The equipment models can include, for example, thermodynamicmodels describing the inputs, outputs, and/or functions performed byvarious sets of building equipment. Equipment models can representcollections of building equipment (e.g., subplants, chiller arrays,etc.) or individual devices (e.g., individual chillers, heaters, pumps,etc.).

Demand response layer 414 can further include or draw upon one or moredemand response policy definitions (e.g., databases, XML files, etc.).The policy definitions can be edited or adjusted by a user (e.g., via agraphical user interface) so that the control actions initiated inresponse to demand inputs can be tailored for the user's application,desired comfort level, particular building equipment, or based on otherconcerns. For example, the demand response policy definitions canspecify which equipment can be turned on or off in response toparticular demand inputs, how long a system or piece of equipment shouldbe turned off, what setpoints can be changed, what the allowable setpoint adjustment range is, how long to hold a high demand set-pointbefore returning to a normally scheduled set-point, how close toapproach capacity limits, which equipment modes to utilize, the energytransfer rates (e.g., the maximum rate, an alarm rate, other rateboundary information, etc.) into and out of energy storage devices(e.g., thermal storage tanks, battery banks, etc.), and when to dispatchon-site generation of energy (e.g., via fuel cells, a motor generatorset, etc.).

Integrated control layer 418 can be configured to use the data input oroutput of building subsystem integration layer 420 and/or demandresponse later 414 to make control decisions. Due to the subsystemintegration provided by building subsystem integration layer 420,integrated control layer 418 can integrate control activities of thesubsystems 428 such that the subsystems 428 behave as a singleintegrated supersystem. In an exemplary embodiment, integrated controllayer 418 includes control logic that uses inputs and outputs from aplurality of building subsystems to provide greater comfort and energysavings relative to the comfort and energy savings that separatesubsystems could provide alone. For example, integrated control layer418 can be configured to use an input from a first subsystem to make anenergy-saving control decision for a second subsystem. Results of thesedecisions can be communicated back to building subsystem integrationlayer 420.

Integrated control layer 418 is shown to be logically below demandresponse layer 414. Integrated control layer 418 can be configured toenhance the effectiveness of demand response layer 414 by enablingbuilding subsystems 428 and their respective control loops to becontrolled in coordination with demand response layer 414. Thisconfiguration may advantageously reduce disruptive demand responsebehavior relative to conventional systems. For example, integratedcontrol layer 418 can be configured to assure that a demandresponse-driven upward adjustment to the set-point for chilled watertemperature (or another component that directly or indirectly affectstemperature) does not result in an increase in fan energy (or otherenergy used to cool a space) that would result in greater total buildingenergy use than was saved at the chiller.

Integrated control layer 418 can be configured to provide feedback todemand response layer 414 so that demand response layer 414 checks thatconstraints (e.g., temperature, lighting levels, etc.) are properlymaintained even while demanded load shedding is in progress. Theconstraints can also include set-point or sensed boundaries relating tosafety, equipment operating limits and performance, comfort, fire codes,electrical codes, energy codes, and the like. Integrated control layer418 is also logically below fault detection and diagnostics layer 416and automated measurement and validation layer 412. Integrated controllayer 418 can be configured to provide calculated inputs (e.g.,aggregations) to these higher levels based on outputs from more than onebuilding subsystem.

Automated measurement and validation (AM&V) layer 412 can be configuredto verify that control strategies commanded by integrated control layer418 or demand response layer 414 are working properly (e.g., using dataaggregated by AM&V layer 412, integrated control layer 418, buildingsubsystem integration layer 420, FDD layer 416, or otherwise). Thecalculations made by AM&V layer 412 can be based on building systemenergy models and/or equipment models for individual BMS devices orsubsystems. For example, AM&V layer 412 can compare a model-predictedoutput with an actual output from building subsystems 428 to determinean accuracy of the model.

Fault detection and diagnostics (FDD) layer 416 can be configured toprovide on-going fault detection for building subsystems 428, buildingsubsystem devices (i.e., building equipment), and control algorithmsused by demand response layer 414 and integrated control layer 418. FDDlayer 416 can receive data inputs from integrated control layer 418,directly from one or more building subsystems or devices, or fromanother data source. FDD layer 416 can automatically diagnose andrespond to detected faults. The responses to detected or diagnosedfaults can include providing an alert message to a user, a maintenancescheduling system, or a control algorithm configured to attempt torepair the fault or to work-around the fault.

FDD layer 416 can be configured to output a specific identification ofthe faulty component or cause of the fault (e.g., loose damper linkage)using detailed subsystem inputs available at building subsystemintegration layer 420. In other exemplary embodiments, FDD layer 416 isconfigured to provide “fault” events to integrated control layer 418which executes control strategies and policies in response to thereceived fault events. According to an exemplary embodiment, FDD layer416 (or a policy executed by an integrated control engine or businessrules engine) can shut-down systems or direct control activities aroundfaulty devices or systems to reduce energy waste, extend equipment life,or ensure proper control response.

FDD layer 416 can be configured to store or access a variety ofdifferent system data stores (or data points for live data). FDD layer416 can use some content of the data stores to identify faults at theequipment level (e.g., specific chiller, specific AHU, specific terminalunit, etc.) and other content to identify faults at component orsubsystem levels. For example, building subsystems 428 can generatetemporal (i.e., time-series) data indicating the performance of BMS 400and the various components thereof. The data generated by buildingsubsystems 428 can include measured or calculated values that exhibitstatistical characteristics and provide information about how thecorresponding system or process (e.g., a temperature control process, aflow control process, etc.) is performing in terms of error from itsset-point. These processes can be examined by FDD layer 416 to exposewhen the system begins to degrade in performance and alert a user torepair the fault before it becomes more severe.

Ethernet Ring Topology Generation

The BMS, as described above, can have multiple individual componentswithin the BMS. Example components may include control devices, such asfield equipment controllers (FECs), advanced application field equipmentcontrollers (FACs), network control engines (NCEs), input/output modules(IOMs), and variable air volume (VAV) modular assemblies. However, othercontrol device types are contemplated. For example, the BMS may includemultiple devices such as sensors, actuators, valves, beacons, switches,thermostats, etc. In some embodiments, some or many of these devices maybe configured as or connected to a network and controlled through thatnetwork. For example, the network may be an Ethernet network arranged ina ring topology. The present disclosure describes a mechanism todynamically and efficiently determine the topology of the devices withinthe ring, thereby allowing for the system configuration to be easilyverified automatically. Further, the mechanism for determining thetopology of the devices within the ring can allow for more efficientidentification of a malfunctioning device within the Ethernet ring whena fault is detected.

Referring now to FIG. 5, a block diagram illustrating an networkedsystem 500 is shown. The system includes an Ethernet ring topologygenerator (RTG) 502, a ring supervisor 504, and a number of devices506-518. As described above, the devices 506-518 may be any type ofdevices within a BMS that are connected via an Ethernet connection. TheRTG 502 may be a remote server, a personal computer, a laptop computer,or other device configured to operate as the topology generator. In oneembodiment, the RTG 502 is a Metasys server from Johnson Controls, Inc.In some embodiments, the RTG 502 must be a device outside of an Ethernetring in order to accurately generate the topology of the devices withinthe Ethernet ring. The RTG 502 is configured to transmit one or morecommands to the devices 506-518 in the Ethernet ring via the ringsupervisor 504. The RTG 502 may further be configured to generate andmanage one or more topology tables associated with an Ethernet ring, andwhich may be used to determine an order and configuration of the devices506-518 arranged in an Ethernet ring 520. In some examples, the RTG 502may also store the topology information in lists, arrays or other datastructures, as applicable. In one embodiment, to determine the topologyof the devices 506-518 of the devices within the Ethernet ring 520, theRTG 502 must determine the following information: the devices in thering, the order of the devices in the ring relative to each other; andhow the devices are connected to each other (i.e., which Ethernet portsconnect two devices in the ring, or which Ethernet ports of a deviceconnects the device to the ring supervisor 504. The processes fordetermining the above information will be described in more detailbelow.

The ring supervisor 504 may be standard Ethernet switch configured tomanage a number of Ethernet-based devices in ring topology. In oneembodiment, the Ring supervisor 504 is configured to host a Dynamic HostControl Protocol (DHCP) server and a MRP ring manager. The ringsupervisor 504 may have a number of Ethernet ports for communicatingwith one or more Ethernet devices or networks. In one embodiment, thering supervisor 504 uses two ports, such as port A and port B tocommunicate with the devices 506-518 and generate an Ethernet ring. Asstated above, the Ethernet ring 520 of system 500 may be configured asan MRP ring. However, the herein disclosed topology determinationmethods and systems are intended to be protocol agnostic, and could beused in various other Ethernet ring protocols, such as a spanning treeprotocol (STP) rings, daisy chain configurations, and/or other Ethernetring protocols. In an MRP ring, an MRP beacon frame may be transmittedto each of the devices 506-518 in the Ethernet ring 520 to inform thedevices 506-518 that they are a member of an MRP ring. The devices506-518, upon receiving the MRP beacon flag, flag themselves as being apart of an MRP ring. In an MRP ring, one device in the ring (e.g. thering supervisor 504) manages the Ethernet ring 520 to preventcontinuous/infinite looping of messages within the Ethernet ring 520.

Each of the devices 506-518 may include a first port and a second port.For example, device A 506 is shown to include Port 1 and Port 2. Oneport may be designated as a receiving port and the other port may be aforwarding port. In one example, when the ring is closed (e.g. there isno break in the connectivity in the ring), the ring supervisor 504 mayblock one of the ports to prevent infinite looping within the ring andforwards all packets received outside the ring to the device on thering. However, both Port 1 and Port 2 may be capable of sending andreceiving data packets, as needed. For example, for device A 506, Port 1is shown as a receiving port, and port 2 is shown as a forwarding port.However, the ports (e.g. port 1 and port 2) may be interchanged betweenbeing a forwarding port and a receiving port based on which port on thering supervisor 504 is being used as a forwarding port. For example, inthe system 500, if Port 4 of the Ring supervisor is used as theforwarding port of the ring supervisor 504, then Port 2 would be thereceiving port and Port 1 would be the forwarding port of device A 506.In a typical ring topology, one port of the ring supervisor 504 is setas the forwarding port to prevent redundant messages from being providedto the Ethernet ring 520.

Turning now to FIG. 6, a data flow chart illustrating a process 600 fordiscovering the devices in an Ethernet ring is shown, according to someembodiments. The process 600 is described in reference to the system 500described above. However, it is contemplated that the process 600 can beused with various other Ethernet networks, as described above. As statedabove, before the topology of the devices 506-518 can be determined, theRTG 502 needs to discover the devices 506-518 that are participating inthe Ethernet ring 520. In some embodiments, the discovery process 600includes discovering the devices 506-518 as well as the ring supervisor504. More specifically, the discovery process 600 determines which portson the ring supervisor 504 are hosting the Ethernet ring 520. In someembodiments, the RTG 502 can be pre-configured with basic informationabout the Ethernet ring 520. For example, the RTG 502 may be configuredwith the IP address of the ring supervisor 504 hosting the Ethernet ring520, and the type of ring (MRP, STP, etc.) being used. This informationcan be used to determine which ring supervisor 504 commands need to beissued to obtain a status of the Ethernet ring 520. Additionally, theRTG 502 may know the switch ports of the ring supervisor 504 used tooperate the ring Ethernet 520, and a subnetwork of the devices in theEthernet ring 520. In some embodiments, a user may provide thisinformation to the RTG 502. In other embodiments, the RTG mayinterrogate the Ring supervisor 504 to obtain the necessary information.

The RTG 502 first transmits a ring status query 602 to determine if theEthernet ring 520 is open or closed. If the ring is closed, the RTG 502determines that all devices 506-518 are reachable and broadcasts adevice discovery broadcast message 604. Upon receiving the devicediscovery broadcast message 604, the devices 506-518 respond bytransmitting a device discovery response 606. The device discoveryresponse 606 may include a device ID, and a device IP address.

Upon receiving a device discovery response 606 from each of the devices506-518, the RTG 502 may create a ring topology data structure andpopulate the data structure with the information within the receiveddevice discovery responses 606. In one embodiment, the data structure isa Ring Topology Table, such as Table 1, shown below.

TABLE 1 Ring Topology Table with Device Discovery Response Data RingTopology Table Ethernet Supervisor Port to Previous Port to Next RingRing Order Port/Ring Device ID Ring Device Device Count Supervisor RingPort N/A N/A Device C Device F Device B Device G Device D Device ADevice E Supervisor Ring Port N/A N/A

After the devices 506-518 of the Ethernet ring are discovered, the RTG502 initiates an Ethernet port orientation process 700, as shown in FIG.7 to orient the ports of the devices 506-518 relative to each other. Inone embodiment, the RTG 502 orients each device's 506-518 ports relativeto the ring supervisor's 504 forwarding ring port. In order to preventinfinite looping when the ring is closed, the ring supervisor 504 mayblock one of its ring ports (Port 3 or Port 4) such that data fromoutside the Ethernet ring 520 is always routed into the Ethernet ring520 through the other ring port (the forwarding port). Therefore, all ofthe device 506-518 will receive messages on their data port which isclosest to the ring supervisor's 504 forwarding port.

In one embodiment, the RTG 502 first transmits a ring status query 702to the ring supervisor 504 to determine if the Ethernet ring 520 is openor closed. If the ring is open, the RTG 502 may abort the Ethernet portorientation process 700. If the ring is closed, the RTG 502 may transmita ring port status query 704 to the ring supervisor 504 to determinewhich port is currently configured as the forwarding port of the ringsupervisor 504, and therefore which port of the ring supervisor 504 isblocked. In one embodiment, the ring status query 702 and the ring portstatus query 704 may be combined into a single query. For purposes ofthis example, the forwarding port is determined to be Port 3, and theblocked port is determined to be Port 4.

The RTG 502 may then broadcast a ring port request message 706 to all ofthe devices 506-518. The devices 506-518 may then respond back to theRTG 502 with a ring port response message 708 containing their DeviceID, and the port on which they received the ring port request message(e.g. port 1 or port 2). In one example, messages from the RTG 502 willbe received on the Ethernet port closest to the forwarding port of thering supervisor 504 for each of the devices 506-518 where the Ethernetring 520 is closed. The port receiving the ring port request message 706therefore is either directly connected to the forwarding port of thering supervisor 504 (port 3), or is connected to the previous device506-518 in the ring relative to the forwarding port of the ringsupervisor 504 (port 3). Therefore, the device's 506-518 other port istherefore connected to either the blocked port of the ring supervisor504 (port 4) or to the next device 506-518 in the Ethernet ring 520,according to some embodiments.

The RTG 502 may then update the Ring Topology table with the datareceived in the ring port response messages 708 received from thedevices 506-518. In one embodiment, the RTG 502 may populate the Port toPrevious Ring Device with the Ethernet port (1 or 2) of each device504-518 based on the data received in the ring port response message708. The Port to Previous Ring Device data points indicate which port ofa given device 506-518 is closest to the ring supervisor's 504forwarding port. The RTG 502 may also populate the Port to Next RingDevice with the Ethernet port (1 or 2) of each device 506-518 based onthe data received in the ring port response message 708. The Port toNext Ring Device data points indicate which port of a device 506-518 isclosest to the Ethernet ring's 520 blocked port (port 4). An exampleupdated Ring Topology Table is shown in Table 2, below.

TABLE 2 Ring Topology Table with Device Port Data Ring Topology TableEthernet Supervisor Port to Previous Port to Next Ring Ring OrderPort/Ring Device ID Ring Device Device Count Supervisor Ring Port N/A 3N/A Device C 2 1 0 Device F 1 2 0 Device B 1 2 0 Device G 2 1 0 Device D1 2 0 Device A 1 2 0 Device E 1 2 0 Supervisor Ring Port 4 N/A N/A

Once the RTG 502 has determined the orientation of each of the devices'506-518 ports relative to the ring supervisor 504, the RTG 502 candetermine an order of the devices in the ring relative to the ringsupervisor's 504 forwarding port. Turning now to FIG. 8, a data flowchart illustrating a process 800 for determining a position of devicesin an Ethernet ring is shown, according to some embodiments. The RTG 502first transmits a ring status query 802 to the ring supervisor 504 todetermine if the Ethernet ring 520 is open or closed. If the Ethernetring 520 is determined to be open, the RTG 502 aborts the process 800.If the Ethernet ring 520 is determined to be closed, the RTG 502 thensends a port status change request message 804 to a first device 506-518of the Ethernet ring 520. In some embodiments, the RTG 502 may transmitthe port status change request message 804 to the device which is listedfirst in the generated ring topology table. However, in otherembodiments, the RTG 502 may transmit the port status change requestmessage to a device based on other criteria.

In one embodiment, the port status change request message 804 includes acommand to disable one ports of the device 506-518 receiving the message804. In one embodiment, the port status change request message 804instructs the device 506-518 receiving the message 804 to disable theport associated with the port to next ring device parameter in the ringtopology table for the associated device 506-518. As shown in FIG. 8,device C 510 may be the first device to receive the port status changerequest message 804. In some embodiments, the device 506-518 currentlyreceiving the port status change request message 804 is referred to asthe reference device. After the device C 510 disables a port, the deviceC 510 may transmit a port status change request message 806 to the RTG502 indicating that the port has been disabled. Upon receiving the portstatus change request message 806, the RTG 502 again transmits a ringstatus query 808 to the ring supervisor 504 to verify that the ring isnow open. Upon verifying that the ring is open, the RTG 502 broadcasts aring port request message 810 to devices 506-518 via the forwarding portof the ring supervisor 504. Each device 506-518 receiving the ring portrequest message 810 may transmit a ring port response message 812 to theRTG 502.

Upon receiving the ring port response messages 812, the RTG 502 firstdetermines if the ring port response message 812 is from the referencedevice (e.g. the device with the currently disabled port). If the ringport response message 812 is from the reference device, the RTG 502ignores the ring port response message 812. For the ring port responsemessages 812 not from the reference device, the RTG 502 then determinesif the ring port response message for each of the other non-referencedevices 506-518 is received from the Ethernet port which matches thePort to Previous Ring Device parameter for each associated device in thering topology table. If the ring port response message 812 is not fromthe reference device, and the Ethernet port from which the ring portresponse message 812 was received matches the port to previous ringdevice parameter within the ring topology table, the RTG 502 incrementsa ring order count parameter in the ring topology table for theassociated device. As only the forwarding port of the ring supervisor504 is active, the RTG 502 will only receive the ring port responsemessages from device 506-518 between the forwarding port of the ringsupervisor 504 and the reference device. At this point the ring is opensuch that the ring supervisor 504 can send the ring port request message810 over both its ring ports (e.g. port 1 and port 2). However, only thedevices which receive the ring port request message 810 via thepreviously defined forwarding port (ie. The Port to Previous Ring Deviceport) will have their Ring Order Count incremented. Thus, as in theabove example where the device C is the initial reference device, afterall of the ring port response messages 812 have been received, the ringorder count parameters values within the ring topology chart will be asshown in Table 3, below.

TABLE 3 Ring Topology Table with Initial Ring Order Count Ring TopologyTable Ethernet Supervisor Port to Previous Port to Next Ring Ring OrderPort/Ring Device ID Ring Device Device Count Supervisor Ring Port N/A 3N/A Device C 2 1 0 Device F 1 2 0 Device B 1 2 1 Device G 2 1 0 Device D1 2 0 Device A 1 2 1 Device E 1 2 0 Supervisor Ring Port 4 N/A N/A

Once the ring port response messages 812 have been received, the RTG 502may transmit a port status change request 814 to the reference device,device C 510. The port status change request 814 can instruct thereference device, device C 510 to re-enable its Ethernet port. Thereference device, device C 510, can then transmit a port status changeresponse 816 to the RTG 502 indicating that the port has beenre-enabled. The port status change response 816 may include a message IDindicating that the message is a port status change response, anEthernet port that was updated, and a result bit associated with theupdated Ethernet port (e.g. 1—port enable, 2—port disabled.). Uponreceiving the port status change response 816, the RTG 502 may transmita port status change request 818 to a subsequent device 506-518 in thering that is different from the previous reference device. Afterreceiving confirmation that the device's Ethernet port has transitionedback to enabled, the RTG 502 may perform another Query Ring Status toconfirm that the ring is now closed, and prior to moving on to the nextdevice with 818. The RTG 502 may then repeat the above process for thenew reference device, and continue until each of the previouslydiscovered devices 506-518 have been designated as the reference device(e.g. had a port disabled.). Upon completion of the process 800, thering topology table may include the following data as shown in Table 4below, based on the system 500.

TABLE 4 Ring Topology Table Including Complete Ring Order Count DataRing Topology Table Ethernet Supervisor Port to Previous Port to NextRing Ring Order Port/Ring Device ID Ring Device Device Count SupervisorRing Port N/A 3 N/A Device C 2 1 4 Device F 1 2 1 Device B 1 2 5 DeviceG 2 1 0 Device D 1 2 3 Device A 1 2 6 Device E 1 2 2 Supervisor RingPort 4 N/A N/A

The RTG 502 may then order then devices 506-518 based on theirrespective ring order count. By ordering the devices 506-518 fromhighest ring order count to lowest ring order count, the devices 506-518will be listed in the order they are installed in the ring in relationto the forwarding port of the ring supervisor 504, as well as how thedevice 506-518 in the ring are connected to each other (e.g., the Portto Previous Ring Device for the first device in the ring topology tableis connected to the ring manager forwarding port, the Port to Next RingDevice of the first device in the ring topology table is connected tothe Port to Previous Ring Device of the second device in the ringtopology table, and so on.). For the system 500 of FIG. 5, the orderedring topology table is shown below in Table 5.

TABLE 5 Ordered Ring Topology Table Ring Topology Table EthernetSupervisor Port to Previous Port to Next Ring Ring Order Port/RingDevice ID Ring Device Device Count Supervisor Ring Port N/A 3 N/A DeviceA 1 2 6 Device B 1 2 5 Device C 2 1 4 Device D 1 2 3 Device E 1 2 2Device F 1 2 1 Device G 2 1 0 Supervisor Ring Port 4 N/A N/A

Turning now to FIG. 9, a flow diagram illustrating a process 900 fordetermining a topology of an Ethernet ring is shown, according to someembodiments. The process 900 may be a combination of the processes 600,700 and 800 described above. In one embodiment, the process 900 operatesat the application layer, allowing the topology of the Ethernet ring 520to be determined by communicating directly with the devices in theEthernet ring, rather than relying on messaging type specific to thering protocol to provide the topology information. In some embodiments,an RTG, such as RTG 502 described above, may be responsible forperforming the various steps of the process 900. In one example, the RTGmay interface with a user, such as via a graphical user interface (GUI),to allow a user to both configure the RTG, but also to present the userwith a graphical representation of the generated ring topology, in someembodiments. In one embodiment, when the RTG is initialized or launched,the RTG will initially generate the topology of the configured Ethernetring as described below. Further, the RTG may continue to monitor thestatus of the ring to determine if/when the topology needs to bere-generated. For example, the RTG may regenerate the ring topologywhenever the ring status transitions from open to closed to account forthe addition/deletion of devices to the Ethernet ring as well as anycabling changes within the Ethernet ring (e.g. if the cables going intoa particular device's Ethernet ports were swapped.)

At process block 902, all the devices within the Ethernet ring aredetermined. In one embodiment, an RTG, such as RTG 502 may execute aprocess to discover all of the devices within the Ethernet ring. Forexample, the RTG may use a process such as process 600 described aboveto discover all the devices in the Ethernet ring. The RTG may alsodetermine other information about the devices, such as IP addresses ofthe devices, device types, associated other devices, associatedsub-networks, or the like.

At process block 904, the RTG may determine a port configuration of thediscovered device. In some embodiments, the RTG may determine the portconfigurations using a process similar to process 700 described above.For example, the RTG may broadcast a ring port request to the devices onthe Ethernet ring. In some embodiments, the RTG first ensures that oneof the ports of an Ethernet ring supervisor associated with the Ethernetring is disabled, ensuring that any message broadcasted by the RTG isonly provided to the Ethernet ring via a single port. By determining theport configurations of the discovered devices, the RTG can determine arelationship of the Ethernet ports of the devices in regards to eachother, and an Ethernet ring supervisor, such as ring supervisor 504. TheRTG may then populate a data structure with the individual deviceswithin the Ethernet ring, as well as the relationships of theirindividual ports. For example, the RTG may populate the data structurewith data such as the “port to previous ring device,” indicating whichport the device received the broadcasted message from the RTG.

At process block 906, the RTG may transmit an instruction to a firstdevice within the Ethernet ring and instruct the first device to disableone of the Ethernet ports of the device. The device with the disabledport may be referred to as the reference device. The RTG may thendetermine if the Ethernet ring is open at process block 908. In someembodiments, the RTG may verify that the Ethernet ring is open byquerying the Ethernet ring supervisor, which can provide a status of theEthernet ring (e.g. whether the Ethernet ring is open or closed). Inother embodiments, the RTG may broadcast a message to the devices on theEthernet ring and determine if a response is issued from all of thedevices, or a portion of the devices, indicating whether the ring isopen or closed.

Once the device determines that the Ethernet ring is open, the RTGbroadcasts a ring port request to the devices in the Ethernet ring atprocess block 910. The ring port request may include a message IDindicating that the message is a ring port request. The ring portrequest may be a standard request in Ethernet ring configurations. Atprocess block 912, the devices receiving the ring port request transmita ring port response to the RTG. The ring port response may include amessage ID, a device ID of the device transmitting the ring portresponse, a result and an Ethernet port message. The device ID may be aunique identifier for the device. For example, the device ID may be aBACnet OID, a logical name, a media access control (MAC) address, orsome other existing ID. The result message may indicate whether the ringport response is successful or unsuccessful. Finally, the Ethernet portmessage may indicate on which port of the device the ring port requestmessage was received. In one embodiment, the Ethernet port message mayonly be included in the ring port response where the result messageindicates that the ring port response was successful. The RTG, havingreceived the ring port responses from each of the devices receiving thering port request increments a count associated with each device fromwhich the ring port response is received. In one embodiment, the RTG mayignore the ring port response received from the reference device (e.g.the device with the disabled port.).

Once all of the ring port responses have been received, the RTG enablesthe previously disabled port on the reference device at process block914. The RTG may further query the ring supervisor to confirm the ringis closed. The RTG then determines if all of the previously discovereddevices within the Ethernet ring have had a port disabled (e.g. has eachdevice been the reference device) at process block 916. If the RTGdetermines that not all of the previous devices have had an Ethernetport disabled, the process 900 returns to process block 906. If the RTGdoes determine that all of the devices have had their Ethernet portsdisabled, the RTG may determine a topology of the Ethernet ring (e.g.determine the order of the discovered devices within the ring) atprocess block 918. In one embodiment, the RTG may determine the topologyof the devices in the Ethernet ring by ordering the devices based on thenumber of ring port responses received from each device. The RTG maythen determine that the device with the highest number of associatedport responses is the device closest to the forwarding port (e.g. activeport) of the Ethernet ring supervisor). Therefore, the device with thelowest number of associated port responses is the device further awayfrom the forwarding port of the Ethernet ring supervisory. Accordingly,the order of the devices, based on the number of received portresponses, will correspond to the position of the device within theEthernet ring with respect to the forwarding port of the Ethernet ringsupervisor.

In some embodiments, the RTG may utilize the generated topology to beable to identify the location of one or more breaks in an Ethernet ring.For example, whenever a ring device's Ethernet port goes out of service(OOS), the device could send a message to the RTG reporting the OOSport. The RTG could then map the port to the current ring topology andmark the port to indicate the OOS status of the port. In otherembodiments, failure or break events should be generated in pairs (i.e.,if one end of a connection between two devices within the Ethernet ringgoes OOS, then the other should as well, such that the RTG should markboth ends of the connection OOS. If another break in the ring isdetected, the connectivity to one or more devices in the ring will belost. The RTG could determine the devices which have no connectivitybased on the most recent ting topology and indicate to a user whichdevices have lost connection.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements may bereversed or otherwise varied and the nature or number of discreteelements or positions may be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepsmay be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions may be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure may be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Combinationsof the above are also included within the scope of machine-readablemedia. Machine-executable instructions include, for example,instructions and data which cause a general purpose computer, specialpurpose computer, or special purpose processing machines to perform acertain function or group of functions.

Although the figures show a specific order of method steps, the order ofthe steps may differ from what is depicted. Also two or more steps maybe performed concurrently or with partial concurrence. Such variationwill depend on the software and hardware systems chosen and on designerchoice. All such variations are within the scope of the disclosure.Likewise, software implementations could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various connection steps, processing steps, comparisonsteps and decision steps.

The invention claimed is:
 1. A method of determining a topology ofdevices in an Ethernet ring, comprising: broadcasting a device discoverycommand from a ring topology generator to the devices in the Ethernetring; receiving device discovery information from one or more of thedevices in the Ethernet ring at the ring topology generator; querying aring supervisor to confirm that the Ethernet ring is closed and todetermine which Ethernet port of the ring supervisor is connected to theEthernet ring as a forwarding port; the ring topology generatorconfigured to, for each discovered device in the Ethernet ring: (i)disabling an Ethernet port of one of the devices in the Ethernet ring;(ii) verifying that the Ethernet ring is open; (iii) broadcasting a ringport request onto the Ethernet ring via the ring supervisor; (iv)receiving a ring port response from each of the devices having receivedthe ring port request; (v) incrementing a count associated with eachdevice based on receiving a ring port response from the device; (vi)re-enabling the Ethernet port of the one of the devices in the Ethernetring; and (vii) repeating steps (i) through (vi) until each device inthe Ethernet ring has had an Ethernet port disabled; and determining thetopology of the devices of the Ethernet ring by ordering the devices inthe Ethernet ring based on a value of the count associated with eachdevice, wherein the device having a highest count value being closest tothe forwarding port of the ring supervisor, and the device having alowest count value being furthest from the forwarding port of the ringsupervisor.
 2. The method of claim 1, wherein the ring topologygenerator does not increment a count for a ring port response from thedevice that currently has the Ethernet port disabled.
 3. The method ofclaim 1, wherein the Ethernet ring is configured as a Media RedundancyProtocol (MRP) ring.
 4. The method of claim 1, wherein the devicediscovery information includes a device identification (ID).
 5. Themethod of claim 4, wherein the device ID is one or more of a mediaaccess control (MAC) address, a building automation control network(BACnet) object identification (OID), and a logical device name.
 6. Themethod of claim 1, further comprising: broadcasting a ring port querymessage based on receiving the device discovery information from the oneor more devices in the Ethernet ring; receiving a ring port queryresponse from the one or more devices in the Ethernet ring; and whereinthe ring topology generator is configured to orient the Ethernet portsof the one or more devices in the Ethernet ring based on the receivedring port query responses.
 7. The method of claim 6, wherein the ringport query response comprises a message identification (ID), a Deviceidentification (ID), and an Ethernet port on which the ring port querymessage was received.
 8. A system for determining a topology of anEthernet ring, the system comprising: a plurality of Ethernet devicesconfigured in the Ethernet ring; a ring supervisor, the ring supervisorintegral to the Ethernet ring and configured to manage data flow withinthe Ethernet ring; and a ring topology generator configured to:broadcast a device discovery command from a ring topology generator tothe devices in the Ethernet ring; receive device discovery informationfrom one or more of the plurality of devices in the Ethernet ring, thereceived device discovery information indicating a discovered device;query the ring supervisor to confirm that the Ethernet ring is closedand to determine which Ethernet port of the ring supervisor is connectedto the Ethernet ring as a forwarding port; execute followinginstructions for each of the discovered devices: (i) disable an Ethernetport of one of discovered devices in the Ethernet ring; (ii) verify thatthe Ethernet ring is open; (iii) broadcast a ring port request onto theEthernet ring via the ring supervisor; (iv) receive a ring port responsefrom each of the discovered devices having received the ring portrequest; (v) increment a count associated with each device based onreceiving a ring port request from the device; (vi) re-enable theEthernet port of the one of the discovered devices; and (vii) repeatsteps (i) through (vi) until each device in the Ethernet ring has had anEthernet port disabled; and determine the topology of the devices on theEthernet ring by ordering the devices in the Ethernet ring based on avalue of the count associated with each device, wherein the devicehaving a highest count value is closest to the forwarding port of thering supervisor, and the device having a lowest count value is thedevice furthest from the forwarding port of the ring supervisor.
 9. Thesystem of claim 8, wherein the ring topology generator does notincrement a count for a ring port response from the device thatcurrently has the Ethernet port disabled.
 10. The system of claim 8,wherein the Ethernet ring is configured as one of a Media RedundancyProtocol (MRP) ring and a Spanning Tree Protocol (STP) ring.
 11. Thesystem of claim 8, wherein the device discovery information comprises adevice identification (ID), the device ID comprising one or more of amedia access control (MAC) address, a building automation controlnetwork (BACnet) object identification (OID), or a logical device name.12. The system of claim 8, wherein the ring topology generator isfurther configured to: broadcast a ring port query message based onreceiving the device discovery information from the one or more devicesin the Ethernet ring; receive a ring port query response from the one ormore devices in the Ethernet ring; and orient the Ethernet ports of theone or more devices in the Ethernet ring based on the received ring portquery responses.
 13. The system of claim 12, wherein the ring port queryresponse comprises a message identification (ID), a Deviceidentification (ID), and an Ethernet port on which the ring port querymessage was received.
 14. A method of determining a topology of devicesin an Ethernet ring, comprising: discovering a number and identificationof devices within the Ethernet ring; for each device discovered in theEthernet ring: (i) disabling an Ethernet port of one of the devices inthe Ethernet ring; (ii) verifying that the Ethernet ring is open; (iii)broadcasting a ring port request onto the Ethernet ring from a ringsupervisor; (iv) receiving a ring port response from each of the deviceshaving received the ring port request; (v) incrementing a countassociated with each device based on receiving a ring port response fromthe device; (vi) re-enabling the previously disabled Ethernet port ofthe one of the devices in the Ethernet ring; and (vii) repeating steps(i) through (vi) until each device in the Ethernet ring has had anEthernet port disabled; and determining the topology of the devices inthe Ethernet ring by ordering the devices in the Ethernet ring based ona value of the count associated with each device, wherein the devicehaving a highest count value being closest to the forwarding port of thering supervisor, and the device having a lowest count value beingfurthest from the forwarding port of the ring supervisor.
 15. The methodof claim 14, wherein discovering the number and identity of devices onthe Ethernet ring comprises: broadcasting a device discovery commandfrom a ring topology generator to the devices in the Ethernet ring; andreceiving device discovery information from the devices in the Ethernetring at the ring topology generator.
 16. The method of claim 15, whereinthe device discovery information includes a device identification (ID),the Device identification (ID) comprising one or more of a media accesscontrol (MAC) address, a building automation control network (BACnet)object identification (OID), and a logical device name.
 17. The methodof claim 15, further comprising: broadcasting a ring port query messageto the Ethernet ring from the ring topology generator based on receivingthe device discovery information from the one or more devices in theEthernet ring; receiving a ring port query response from the one or moredevices in the Ethernet ring; and wherein the ring topology generator isconfigured to orient the Ethernet ports of the one or more devices inthe Ethernet ring based on the received port query responses.
 18. Themethod of claim 17, wherein the ring port response comprises a messageidentification (ID), a Device identification (ID), and an Ethernet portidentification on which the ring port query message was received. 19.The method of claim 14, wherein the count for the ring port responsereceived from the device that currently has the Ethernet port disabledis not incremented while the Ethernet port is disabled.
 20. The methodof claim 14, wherein the Ethernet ring is configured as a MediaRedundancy Protocol (MRP) ring.